To: OpenDoc Development Framework Discussion List, ODF-Interest@CILabs.
I wrote:
" ...I'm writing a faceless part editor that is communicated with
via AppleEvents; the preferred method of interprocess communication for
MacOS 8. I'm also conforming to the AppleEvent Registry Core Suite fully
('cause its the right thing to do!).
So long as my service doesn't require any co-operative services, the part
editor should be able to run as a pre-emptive task in the future
(providing that OpenDoc enables this to happen with MacOS 8)."
Greg Friedman wrote:
"I'll say this again: I don't think it is a good idea to try to write a
"faceless" OpenDoc part. I also think that trying to make such a part
scriptable will be seriously confusing to users."
Making a part editor scriptable doesn't necessarily mean that users will communicate directly with it. I'm doing it 'cause I really want to support AppleEvents and this seems to be the way that its done i.e. no real overhead for the additional support of being scriptable. Someone please correct me if I'm wrong.
Also, by using script running capabilities within my service's clients, I can factor out the calls made to the service. Thus, my client code becomes simplified. Again, someone please correct me if I'm wrong.
Access to my service from the user's perspective may be performed via parts that access the service i.e the service may be effectively adopted by the client part.
Greg Friedman wrote:
"I seriously suggest you investigate alternative implementations. I'm still
not sure why extensions or even a shared library won't work in this case."
AppleEvents. There's no event loop in a shared library.
Also, how about my comment re. co-operative vs re-entrable service access? I'm really striving to have this service be something that can occur behind the scenes. Greg hasn't addressed this goal in his response. ;^)
